Agreed.

Here's my understanding so far: We want our process to be as thorough as necessary while also as light and nimble as possible. Before we commit to changes, we want to ensure the code, design, and security analysis all match, so we need to get the engineering and science teams synchronized on these kinds of changes.

However, for nimbleness and speed, we don't want a process that's too heavy. For that reason, I suggest that for now we:

• can make design changes first, then do both engineering implementation and science review independently from there. This means we may do engineering work on something only to learn later than some scientific flaw is discovered, but I think that risk is worth it in order to have faster engineering progress.
• do review / analysis process with a combination of github PRs to the specs / design docs (in this repo) as well as meeting topics, ml posts, etc...
• don't use bip/pip-style proposal / acceptance review until "1.0 feature freeze" timeframe.

I have a draft ZIP 0 describing the process, which is based very loosely on BIP 1.

We're now revisiting this goal and talking about the ZIP process.